The present invention relates to creating executable programs for a computer system, and more specifically, to translating software code by employing semantic values.
Computer programs are typically composed of one or more components called binary objects. Each binary object represents a portion of the executable code, or module, that constitutes the program of which it is a component. The binary objects are typically created by a compiler (also called a translator) that converts software code written in a higher level language into the binary object.
The binary objects are then linked together to compose a complete executable program. The software tool that performs this task is called a linker.
Before a program can be run, it must be loaded into a computer's memory. The component of the operating system that performs this task is called the program loader. For a variety of reasons, some components of the program might not be linked to the program by the linker. Instead, these components are added to the executable by the loader. Such components are typically called shared objects, shared libraries, or dynamically loaded libraries.
One of the benefits of partitioning a program into a multitude of binary objects is modularity. It is possible that the source code corresponding to one binary object can be altered without necessitating changes to every other binary object. In particular, only the binary object whose source code has been altered needs to be translated again, using a compiler. Unaffected modules, including shared libraries, need not be retranslated.
The linker/loader technology that is used pervasively in contemporary operating systems, including but not limited to AIX, Linux, Windows, and Z/OS was devised before the advent of popular Object Oriented programming languages. As such, these languages introduce new complexities that are not well served by the sort of modularity that is available today. Specifically, some activities that commonly arise in the day-to-day work of the Object Oriented programmer require that an entire program be retranslated, not just the binary objects that are directly affected. These activities may include but are not limited to: adding virtual functions to a class interface; removing virtual functions from a class interface; factoring virtual functions into the interface of a base class; adding data members to a class interface; and adding a new base class to an existing class.
The inability to perform these activities without recompiling all of a program's constituent binary objects, including its shared libraries, is an enormous limitation. A single shared library may be used by many separate application programs. As a result should any of these changes be made within a shared library every application program of which the shared library is a component must also be retranslated (recompiled). This is often impossible because the user of the application is not a skilled programmer, does not possess the appropriate software tools, or does not have access to the program source code. Further, the user may have no control over modules to link to in the future, or from past development. As a result, authors of shared libraries are severely constrained with respect to the kinds of changes they can make to their software. In some cases, these constraints make it impossible to fix even simple bugs. This is known in the literature as the Release-to-Release Binary Compatibility (RRBC) Problem.